Network Working Group J. Houttuin 


Request for Comments: 1615 RARE Secretariat 
RARE Technical Report: 9 J. Craigie 
Category: Informational Joint Network Team 

May 1994 


Migrating from X.400(84) to X.400(88) 
Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Scope 


In the context of a European pilot for an X.400(88) messaging 
service, this document compares such a service to its X.400(84) 
predecessor. It is aimed at a technical audience with a knowledge of 
electronic mail in general and X.400 protocols in particular. 


Abstract 


This document compares X.400(88) to X.400(84) and describes what 
problems can be anticipated in the migration, especially considering 
the migration from the existing X.400(84) infrastructure created by 
the COSINE MHS project to an X.400(88) infrastructure. It not only 
describes the technical complications, but also the effect the 
transition will have on the end users, especially concerning 
interworking between end users of the 84 and the 88 services. 
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1. New Functionality 


Apart from the greater maturity of the standard and the fact that it 
makes proper use of the Presentation Layer, the principal features of 
most use to the European R&D world in X.400(88) not contained in 
X.400(84) are: 


- A powerful mechanism for arbitrarily nested Distribution 
Lists including the ability for DL owners to control access 
to their lists and to control the destination of nondelivery 
reports. The current endemic use of DLs in the research 
community makes this a fundamental requirement. 


- The Message Store (MS) and its associated protocol, P7. The 
Message Store provides a server for remote User Agents (UAs) 
on Workstations and PCs enabling messages to be held for 
their recipient, solving the problems of non-continuous 
availability and variability of network addresses of such 
UAs. It provides powerful selection mechanisms allowing the 
user to select messages from the store to be transferred to 
the workstation/PC. This facility is not catered for 
adequately by the P3 protocol of X.400(84) and provides a 
major incentive for transition. 


- Use of X.500 Directories. Support for use of Directory Names 
in MHS will allow a transition from use of O/R Addresses to 
Directory Names when X.500 Directories become widespread, 
thus removing the need for users to know about MHS 
topological addressing components. 


— The provision of message Security services including 
authentication, confidentiality, integrity and non- 
repudiation as well as secure access between MHS components 
may be important for a section of the research community. 


— Redirection of messages, both by the recipient if 
temporarily unable to receive them, and by the originator in 
the event of failure to deliver to the intended recipient. 


- Use of additional message body encodings such as ISO 8613 


ODA (Office Document Architecture) reformattable documents or 
proprietary word processor formats. 
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- Physical Delivery services that cater for the delivery of an 
electronic message on a physical medium (such as paper) 
through the normal postal delivery services to a recipient 
who (presumably) does not use electronic mail. 


-— The use of different body parts. In addition to the 
extensible externally defined body parts, the most common 
types are predefined in the standard. In order to give end- 
users a real advantage as compared to other technologies, the 
following body-parts should be supported as a minimum: 


—- TA5 

- Message 

G3FAX 

External 
—- General Text 
- Others 


The last bullet should be interpreted as follows: all UAs 
should be configurable to use any type of externally defined 
body part, but as a minimum General Text can be generated and 
read. 


- The use of extended character sets, both in O/R addresses 
and in the General Text extended bodypart. As a minimum, the 
character sets as described in the European profiles will be 
supported. A management domain may choose as an internal 
matter which character sets it wants to support in 
generating, but all user agents must be able to copy (in 
local address books and in replies) any O/R address, even if 
it contains character sets it cannot interpret itself. 


2. OSI Supporting Layers 


The development of OSI Upper Layer Architecture since 1984 allows the 
new MHS standards to sit on the complete OSI stack, unlike X.400(84). 
A new definition of the Reliable Transfer Service (RTS), ISO 9066, 
has a mode of operation, Normal-mode, which uses ACSE and the OSI 
Presentation Layer. It also defines another mode compatible with 
X.410(84) RTS that was intended only for interworking with X.400 (84) 
systems. 


However, there are differences between the conformance requirements 
of ISO MOTIS and CCITT X.400(88) for mandatory support for the 
complete OSI stack. ISO specify use of Normal-mode RTS as a mandatory 
requirement with X.410-mode RTS as an additional option, whereas 
CCITT require X.410-mode and have Normal-mode optional. The ISO 
standard identifies three MTA types to provide options in RTS modes: 
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- MTA Type A supports only Normal-mode RTS, and provides 
interworking within a PRMD and with other PRMDs (conforming 
to ISO 10021), and with ADMDs which have complete 
implementations of X.400(88) or which conform to ISO 10021. 


—- MTA Type B adds to the functionality of MTA type A the 
ability to interwork with ADMDs implementing only the minimal 
requirements of X.400 (88), by requiring support for X.410- 
mode RTS in addition to Normal-mode. 


-— MTA Type C adds to the functionality of MTA type B the 
ability to interwork with external X.400(84) Management 
Domains (MDs, i.e., PRMDs and ADMDs), by requiring support for 
downgrading (see 5.1) to the X.400(84) P1 protocol. 


The interworking between ISO and CCITT conformant systems is 
summarised in the following table: 


CCITT 
X.400 (84) X.400 (88) 
minimal complete 
implementation 
ISO 10021/ MTA Type A N N Y 
MOTIS MTA Type B N Y Y 
MTA Type C Y Y Y 


Table 1: Interworking ISO <-> CCITT systems 


The RTS conformance difference would totally prevent interworking 
between the two versions of the standard if implementations never 
contained more than the minimum requirements for conformance, but in 
practice many 88 implementations will be extensions of 84 systems, 
and will thus support both modes of RTS. (At the moment we are aware 
of only one product that doesn’t support Normal mode.) 


Both ISO and CCITT standards require P7 (and P3) to be supported 
directly over the Remote Operations Service (ROS), ISO 9072, and use 
Normal-mode presentation (and not X.410-mode). Both allow optionally 
ROS over RTS (in case the Transport Service doesn’t provide an 
adequately reliable service), again using Normal-mode and not X.410- 
mode. 


CCITT made both Normal and X.410 mode mandatory in its X.400 (92) 
version, and it is expected that the 94 version will have the X.410 
mode as an option only. 
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3. General Extension Mechanism 


One of the major assets in ISO 10021/xX.400(88) is the extension 
mechanism. This is used to carry most of the extensions defined in 
these standards, but its principal benefit will be in reducing the 
trauma of transitions to future versions of the standards. Provided 
that implementations of the 88 standards do not try to place 
restrictions on the values that may be present, any future extension 
will be relayed by these implementations when appropriate (i.e., when 
the extension is not critical), thus providing a painless migration 
to new versions of the standards. 


4. Interworking 
4.1. Mixed 84/88 Domains 


ISO 10021-6/X.419(88) defines rules for interworking with X.400(84), 
called downgrading. As X.400 specifies the interconnection of MDs, 
these rules define the actions necessary by an X.400(88) MD to 
communicate with an X.400(84) MD. The interworking rules thus apply 
at domain boundaries. Although it would not be difficult to extend 
these to rules to convert Internal Trace formats which might be 
thought a sufficient addition to allow mixed X.400 (84) /X.400 (88) 
domains, the problems involved in attempting to define mixed 84/88 
domains are not quite that simple. 


The principle problem is in precisely defining the standard that 
would be used between MTAs within an X.400(84) domain, as X.400(84) 
only defines the interconnection of MDs. In practice, MTA 
implementations either use X.400(84) unmodified, or X.400(84) with 
the addition of Internal Trace from the first MOTIS DIS (DIS 8883), 
or support MOTIS as defined in DIS 8505, DIS 8883, and DIS 9065. The 
second option is recommended in the NBS Implementors Agreements, and 
the third option is in conformance with the CEN/CENELEC MHS 
Functional Standard [1], which requires as a minimum tolerance of all 
"original MOTIS" protocol extensions. An 84 MD must decide which of 
these options it will adopt, and then require all its MTAs to adopt 
(or at least be compatible with) this choice. No doubt this is one of 
the reasons for the almost total absence currently of mixed- vendor 
X.400(84) MDs in the European R&D MHS community. The fact that none 
of these three options for communication between MTAs within a domain 
have any status within the standardisation bodies accounts for the 
absence from ISO 10021/X.400(88) of detailed rules for interworking 
within mixed 84/88 domains. 


Use of the first option, unmodified X.400(84), carries the danger of 
undetectable routing loops occurring. Although these can only occur 
if MTAs have inconsistent routing tables, the absence of standardised 
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methods of disseminating routing information makes this a possibility 
which if it occurred might cause severe disruption before being 
detected. The only addition to the interworking rules needed for this 
case is the deletion of Internal Trace when downgrading a message. 


Use of the second option, X.400(84) plus Internal Trace, allows the 
detection and prevention of routing loops. Details of the mapping 
between original-MOTIS Internal Trace and the Internal Trace of ISO 
10021 can be found in Annex A. This should be applied not only when 
downgrading from 88 to 84, but also in reverse when an 84 MPDU is 
received by the 84/88 Interworking MTA. If the 84 domain properly 
implements routing loop detection algorithms, then this will allow 
completely consistent reception of messages by an 84 recipient even 
after DL expansion or Redirection within that domain (but see also 
section 5.3). Unfortunately, the first DIS MOTIS like X.400(84) left 
far too much to inference, so not all implementors may have 
understood that routing loop detection algorithms must only consider 
that part of the trace after the last redirection flag in the trace 
sequence. 


Use of the third option, tolerance of all original-MOTIS extensions, 
would in principle allow a still higher level of interworking between 
the 84 and 88 systems. However, no implementations are known which do 
more than relay the syntax of original-MOTIS extensions: there is no 
capability to generate these protocol elements or ability to 
correctly interpret their semantics. 


The choice between the first two options for mixed domains can be 
left to individual management domains. It has no impact on other 
domains provided the topology recommended in section 5 is adopted. 


4.2. Generation of OR-Name Extensions from X.400(84) 


The interworking rules defined in DIS 10021-6/X.419 Annex B allow for 
delivery of 88 messages to 84 recipients, but do not make any 88 
extensions available to 84 originators. In general this is an 
adequate strategy. Most 88 extensions provide optional services or 
have sensible defaults. The exception to this is the OR-Name 
extensions. These fall into three categories: the new CommonName 
attribute; fifteen new attributes for addressing physical delivery 
recipients; and alternative Teletex (T.61) encodings for all 
attributes that were defined as Printable Strings. Without some 
mechanism to generate these attributes, 84 originators are unable to 
address 88 recipients with OR-Addresses containing these attributes. 
Such a mechanism is defined in RARE Technical Report 3 ([2]), "X.400 
1988 to 1984 downgrading". 
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Common-name appears likely to be a widely used attribute because it 
remedies a serious deficiency in the X.400(84) OR-Name: it provides 
an attribute suitable for naming Distribution Lists and roles, and 
even individuals where the constraints of the 84 personal-name 
structure are inappropriate or undesirable. As 84 originators will no 
doubt wish to be able to address 88 DLs (and roles), [2] defines a 
Domain Defined Attribute (DDA) to enable generation of common-name by 
84 originators. This consists of a DDA with its type set to "common- 
name" and its value containing the Printable String encoding to be 
set into the 88 common-name attribute. 


This requires that all European R&D MHS 88 MTAs capable of 
interworking with 84 systems shall be able to map the value of 
"common-name" DDA in OR-Names received from 84 systems to the 88 
standard attribute extension component common-name, and vice versa. 


X.400(84) originators will only be able to make use of this ability 
to address 88 common-name recipients if their system is capable of 
generating DDAs. Unfortunately, one of the many serious deficiencies 
with the CEN/CENELEC and CEPT 84 MHS Functional Standards ([1] and 
[3]), as originally published, is that this ability is not a 
requirement for all conformant systems. Thus if existing European R&D 
MHS X.400(84) users wish to be able to address a significant part of 
the ISO 10021/X.400(84) world they must explicitly ensure that their 
84 systems are capable of generating DDAs. However, this will be a 
requirement in the revised versions of ENV 41201 and ENV 41202, which 
are to be published soon. There is no alternative mechanism for 
providing this functionality to 84 users. It is estimated that 
currently 95% of all European R&D MHS users are able to generate 
DDAs. 


When messages are sent to both ISO 10021/X.400(88) and X.400 (84) 
recipients outside the European R&D MHS community, this 
representation of common-name will not enable the external recipients 
to communicate directly unless their 84/88 interworking MTA also 
implements this mapping. However, use of this mapping within the 
European R&D MHS community has not reduced external connectivity, and 
provided RTR 3, RFC 1328 is universally implemented within this 
community it will enhance connectivity within the community. 


As for the new Physical Delivery address attributes in X.400(88), RTR 
3 (RFC1328) takes the following approach. A DDA with type "X400-88" 
is used, whose value is an std-or encoding of the address as defined 
in RARE Technical Report 2 ([4]), "Mapping between X.400 (1988) /ISO 
10021 and RFC 822". This allows source routing through an appropriate 
gateway. Where the generated address is longer than 128 characters, 
up to three overflow DDAs are used: X400-C1; X400-C2; X400-C3. This 
solution is general, and does not require co-operation, i.e., it can 
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be implemented in the gateways only. 


Note that the two DDA solutions mentioned above have the undesirable 
property that the P2 heading will still contain the DDA form, unless 
content upgrading is also done. In order to shield the user from 
cryptic DDAs, such content upgrading is in general recommended, also 
for nested forwarded messages, even though the available standards 
and profiles do not dictate this. 


4.3. Distribution List Interworking with X.400 (84) 


Before all X.400(84) systems are upgraded to ISO 10021, the 
interaction of Distribution Lists with X.400(84) merits special 
attention as DLs are already widely used. 


Nothing, apart perhaps from the inability to generate the DL’s OR- 
Address if the DL uses the common-name attribute, prevents an 
X.400(84) originator from submitting a message to a DL. 


X.400(84) users can also be members (i.e., recipients) of a DL. 
However, if the X.400(84) systems involved correctly implement 
routing loop detection, the X.400(84) recipient may not receive all 
messages sent to the DL. X.400(84) routing loop detection involves a 
recipient MD in scanning previous entries in a message’s trace 
sequence for an occurrence of its own domain, and if such an entry is 
found the message is non-delivered. The new standards extend the 
trace information to contain flags to indicate DL-expansion and 
redirection, and re-define the routing loop detection algorithm to 
only examine trace elements from the last occurrence of either of 
these flags. Thus 88 systems allow a message to re-traverse an MD (or 
be relayed again by an MTA) after either DL-expansion or redirection. 
However, these flags cannot be included in X.400(84) trace, so are 
deleted on downgrading. Therefore the 84 DL recipient will receive 
all messages sent to the DL except those which had a common point in 
the path to the DL expansion point with the path from the expansion 
points to his UA. This common point is an MD in the case of a DL in 
another MD or an MTA in the case of a DL in the same MD. Although 
this is quite deterministic behaviour, the user is unlikely to 
understand it and instead regard it as erratic or inconsistent 
behaviour. 


Another problem with X.400(84) DL members will be that delivery and 
non-delivery reports will be sent back directly to the originator of 
a message, rather than routed through the hierarchy of DL expansion 
points where they could have been routed to the DL administrator 
instead of (or as well as) the originator. 
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No general solution to this problem has yet been devised, despite 
much thought from a number of experts. The nub of the problem is that 
changing the downgrading rules to enable 84 recipients to receive all 
such messages also allows the possibility of undetectable infinite DL 
or redirection looping where there is an 84 transit domain. 


A potential solution is to extend the DL expansion procedures to 
explicitly identify X.400(84) recipients and to treat them specially, 
at least by deleting all trace prior to the expansion point. This 
solution is only dangerous if another DL reached through an 84 
transit domain is inadvertently configured as an 84 recipient, when 
infinite looping could occur. It does however impose the problems of 
84 interworking into MHS components which need to know nothing even 
of the existence of X.400(84). It also requires changes to the 
Directory attribute mhs-dl-members to accommodate the indication that 
identifies the recipient as an X.400 (84) user, unless European R&D 
MHS DLs are restricted to being implemented by local tables rather 
than making use of the Directory. 


A similar change would be required for Redirection. However, the 
change for Redirection would have substantially more impact as it 
would require European R&D MHS-specific MHS protocol extensions to 
identify the redirected recipient as an X.400(84) user. If the 
European R&D MHS adopts a reasonable quality of MHS(88) service, all 
its MTAs would be capable of Redirection and all UAs would be capable 
of requesting originator-specified-alternate-recipient and thus be 
required to incorporate these non-standard additions. A special 
European R&D MHS modification affecting all MTAs and UAs seems 
impractical, too! 


If the recommended European R&D MHS topology for MHS migration (See 
chapter 5) is adopted there will never be an X.400(84) transit domain 
(or MTA) between two ISO 10021 systems. This allows the deletion of 
trace prior to the last DL expansion or redirection to be performed 
as part of the downgrading, giving the X.400(84) user a consistent 
service. This solution has the advantage of only requiring changes at 
the convertors between X.400(84) and ISO 10021/X.400(88), where other 
European R&D MHS specific extensions have also been identified. A 
precise specification of this solution is given in Annex A. 


Finally, problems might occur because some X.400(84) MTAs could 
object to messages containing more than one recipient with the same 
extension-id (called originally-requested-recipient-—number in the new 
standards), since this was not defined in X.400(84). Note that 
X.400(84) only requires that all extension-id’s be different at 
submission time, so 84 software that does not except messages with 
identical extension-id’s for relaying or delivery must be considered 
broken. 
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4.4. P2 Interworking 


RTR 3, RFC 1328 also defines the downgrading rules for P2 (IPM) 
interworking: The IPM service in X.400(1984) is usually provided by 
content type 2. In many cases, it will be useful for a gateway to 
downgrade P2 from content type 22 to 2. This will clearly need to be 
made dependent on the destination, as it is quite possible to carry 
content type 22 over P1(1984). The decision to make this downgrade 
will be on the basis of gateway configuration. 


When a gateway downgrades from 22 to 2, the following should be done: 


1. Strip any 1988 specific headings (language indication, and 
partial message indication). 


2. Downgrade all O/R addresses, as described in Section 3. 


3. If a directory name is present, there is no method to 
preserve the semantics within a 1984 O/R Address. However, it 
is possible to pass the information across, so that the 
information in the Distinguished Name can be informally 
displayed to the end user. This is done by appending a text 
representation of the Distinguished Name to the Free Form 
Name enclosed in round brackets. It is recommended that the 
"User Friendly Name" syntax is used to represent the 
Distinguished Name [5]. For example: 


(Steve Hardcastle-Kille, Computer Science, 
University College London, GB) 


4. The issue of body part downgrade is discussed in Section 6. 


Note that a message represented as content type 22 may have 
originated from [6]. The downgrade for this type of message can be 
improved. This is discussed in RTR 2, RFC 1327. 


Note that the newer EWOS/ETSI recommendations specify further rules 
for downgrading, which are not all completely compatible with the 
rules in RTR 3, RFC 1328. This paper does not state which set of 
rules is preferred for the European R&D MHS, it only states that a 
choice will have to be made. 


As the transition topology recommended for the European R&D MHS is to 
never use 84 transit systems between 88 systems, it is possible to 
improve on the P2 originator downgrading and resending scenario. The 
absence of 84 transit systems means that the necessity for a Pl 
downgrade implies that the recipient is on an 84 system, and thus 
that it is better to downgrade 88 P2 contents to 84 P2 rather than to 
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relay it in the knowledge that it will not be delivered. 
5. Topology for Migration 


Having decided that a transition from X.400(84) is appropriate, it is 
necessary to consider the degree of planning and co- ordination 
required to preserve interworking during the transition. 


It is assumed as a fundamental tenet that interworking must be 
preserved during the transition. This requires that one or more 
system in the European R&D MHS community must act as a protocol 
converter by implementing the rules for "Interworking with 1984 
Systems" listed in Annex B of ISO 10021-6/X.419. 


When downgrading from ISO 10021/X.400(88) to X.400(84) all extensions 
giving functionality beyond X.400(84) are discarded, or if a critical 
extension is present then downgrading fails and a non-delivery 
results. Thus, although it is possible to construct topologies of 
interconnected MTAs so that two 88 MTAs can only communicate by 
relaying through one or more 84 MTA, to maximise the quality of 
service which can be provided in the European R&D MHS community it is 
proposed that it require that no two European R&D MHS 88 MTAs shall 
need to communicate by relaying through a X.400(84) MTA. Furthermore, 
if this is extended to require that no two European R&D MHS 88 MTAs 
shall ever communicate by relaying through an X.400(84) MTA, then the 
European R&D MHS can provide enhanced interworking functionality to 
its X.400(84) users. 


If mixed vintage 88 and 84 Management Domains (MDs) are created, the 
routing loop detection rules, which specify that a message shall not 
re-enter an MD it has previously traversed, require that downgrading 
is performed within that mixed vintage MD. That MD therefore requires 
at least one MTA capable of downgrading from 88 to 84. It is unlikely 
that every MTA within an MD will be configured to act as an entry- 
point to that MD from other MDs. However, the proposed European R&D 
MHS migration topology requires that as soon as a domain has an 88 
MTA it shall also have an 88 entry point - this may, of course, be 
that same MTA. 


Even for MDs operating all the same MHS vintage internally, providing 
entry-points for both MHS vintages will give considerable advantage 
in maximising the connectivity to other MDs. Initially, it will be 
particularly important for 88 MDs to be able to communicate with 84 
only MDs, but as 88 becomes more widespread eventually the 84 MDs 
will become a minority for which the ability to support 88 will be 
important to maintain connectivity. For most practical MDs providing 
entry-points that implement options in the supporting layers will 
also be important. Support for at least the following is recommended 
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at MD entry-points: 


88-P1/Normal-mode RTS/CONS/X.25 (84) 
88-P1/Normal-mode RTS/RFC1006/TCP/IP 
84-P1/X.25(80) 

84-P1/RFC1006/TCP/IP 


The above table omits layers where the choice is obvious (e.g., 
Transport class zero), or where no choice exists (e.g., RTS for 84- 
Pl). 


The requirement for no intermediate 84 systems does require that the 
European R&D MHS use direct PRMD to PRMD routing between 88 PRMDs at 
least until such time as all ADMDs will relay the 88 MHS protocols. 


Finally, in order to keep routing co-ordination overhead to a 
minimum, an important requirement for the migration strategy is that 
only one common set of routing procedures is used for both 84 and 88 
systems in the European R&D MHS. 


6. Conclusion 


1. The transition from X.400(84) to ISO 10021/X.400(88) is 
worthwhile for the European R&D MHS, to provide: 


- P7 Message Store to support remote UAs. 
- Distribution Lists. 

- Support for Directory Names. 

- Standardised external Body Part types. 
- Redirection. 

- Security. 

— Future extensibility. 

- Physical Delivery. 


2. To minimise the number of transitions the European R&D MHS 
target should be ISO 10021 rather than CCITT X.400(88) - 
i.e., straight to use of the full OSI stack with Normal-mode 
RTS. 


3. To give a useful quality of service, the European R&D MHS 
should not use minimal 88 MTAs which relay the syntax but 
understand none of the semantics of extensions. In 
particular, all European R&D MHS 88 MTAs should generate 
reports containing extensions copied from the subject message 
and route reports through the DL expansion hierarchy where 
appropriate. 
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4. The European R&D MHS should carefully plan the transition so 
that it is never necessary to relay through an 84 system to 
provide connectivity between any two 88 systems. 


5. The European R&D MHS should consider the additional 
functionality that can be provided to X.400(84) users by 
adopting an enhanced specification of the interworking rules 
between X.400(84) and ISO 10021/X.400(88), and weigh this 
against the cost of building and maintaining its own 
convertors. The advantages to X.400(84) users are: 


- Ability to generate 88 common-name attribute, likely to 
be widely used for naming DLs. 

- Consistent reception of DL-expanded and Redirected 
messages. 

- Ability to receive extended 88 P2 contents 
automatically downgraded to 84 P2. 


7. Security Considerations 


Security issues are not discussed in this memo. 
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Appendix A - DL-expanded and Redirected Messages in X.400 (84) 


This Annex provides an additional to the rules for "Interworking with 
1984 Systems" contained in Annex B of ISO 10021-6/X.419, to give 
X.400(84) recipients consistent reception of messages that have been 
expanded by a DL or redirected. It is applicable only if the 
transition topology for the European R&D MHS recommended in section 
3 is adopted. 


Replace the first paragraph of B.2.3 by: 


If an other-actions element is present in any trace- information- 
elements, that other-actions element and all preceding trace- 
information-elements shall be deleted. If an other-actions element is 
present in any subject-intermediate-trace-information- elements, that 
other-actions element shall be deleted. 
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Appendix C - MHS Terminology 


Message Handling is performed by four types of functional entity: 
User Agents (UAsS) which enable the user to compose, send, receive, 
read and otherwise process messages; Message Transfer Agents (MTAs) 
which provide store-and-forward relaying services; Message Stores 
(MSs) which act on behalf of UAs located remotely from their 


associated MTA (e.g., UAs on PCs or workstations); and Access Units 
(AUs) which interface MHS to other communications media (e.g., Telex, 
Teletex, Fax, Postal Services). Each UA (and MS, and AU) is served by 


a single MTA, which provides that user’s interface into the Message 
Transfer Service (MTS). 


Collections of MTAs (and their associated UAs, MSs and AUs) which are 
operated by or under the aegis of a single management authority are 
termed a Management Domain (MD). Two types of MD are defined: an 
ADMD, which provides a global public message relaying service 
directly or indirectly to all other ADMDs; and a PRMD operated by a 
private concern to serve its own users. 


A Message is comprised of an envelope and its contents. Apart from 
the MTS content-conversion service, the content is not examined or 
modified by the MTS which uses the envelope alone to provide the 
information required to convey the message to its destination. 


The MTS is the store-and-forward message relay service provided by 


the set of all MTAs. MTAs communicate with each other using the P1 
Message Transfer protocol. 
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Appendix D - Abbreviations 


ACSE Association Control Service Element 

ADMD Administration Management Domain 

ASCII American Standard Code for Information Exchange 

ASN.1 Abstract Syntax Notation One 

AU Access Unit 

CCITT Comite Consultatif International de Telegraphique et 
Telephonique 

CEN Comite Europeen de Normalisation 

CENELEC Comite Europeen de Normalisation Electrotechnique 

CEPT Conference Europeene des Postes et Telecommunications 

CONS Connection Oriented Network Service 

COSINE Co-operation for OSI networking in Europe 

DL Distribution List 

DIS Draft International Standard 

EN European Norm 

ENV Draft EN, European functional standard 

IEC International Electrotechnical Commission 

IPM Inter-Personal Message 

IPMS Inter-Personal Messaging Service 

IPN Inter-Personal Notification 

ISO International Organisation for Standardisation 

JNT Joint Network Team (UK) 

JTC Joint Technical Committee (ISO/IEC) 

MD Management Domain (either an ADMD or a PRMD) 

MHS Message Handling System 

MOTIS Message-Oriented Text Interchange Systems 

MTA Message Transfer Agent 

MTL Message Transfer Layer 

MTS Message Transfer System 

NBS National Bureau of Standardization 

OSI Open Systems Interconnection 

PRMD Private Management Domain 

RARE Reseaux Associes pour la Recherche Europeenne 

RFC Request for Comments 

RTR RARE Technical Report 

RTS Reliable Transfer Service 


WG-MSG RARE Working Group on Mail and Messaging 
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